iT邦幫忙

2022 iThome 鐵人賽

DAY 2
0

前情提要

既然被強迫推銷了防禦魔法,來問看看到底是指什麼好了。

「所以說防禦魔法到底是指?」

「那就要從很久很久以前開始說起了…. 在很久很久以前有個遠得要命王國,住著一群魔法師,他們共同建築了複雜精密運算的魔法陣,但難免會有疏失的時候,這時候偉大的防禦魔法誕生了,防禦魔法的歷史在 1XXX 年 (下略一百字….」

「暫停一下!所以防禦魔法是可以抵禦外敵入侵的意思囉?」

「不是耶!」

「等等等,那它拿來防禦誰?」

「自己!」

「防自己,防自己做什麼!?」

看著綠繡眼型態的艾草一臉悲傷的樣子,我把還想質疑的話默默的吞了進去,緩緩地開口道:

「阿不然,你就講解看看好了啦!」

https://ithelp.ithome.com.tw/upload/images/20220917/201390664H3nOqtUIG.png


單元測試

針對程式碼最小單位,如 function 去進行測試,通常撰寫者為工程師,擁有幾個特點:

  • 測試的最小單位
  • 當測試出錯時,很容易找出問題點
  • 撰寫單元測試相較其他幾種測試更節省時間
  • 單一單元測試失敗時,通常不會影響到其他單元測試

單元測試可以測試一小段程式碼或一個流程的功能功能,以一個表單為例:一小段程式碼可能會是使用者是否有輸入值的判斷,而一整個流程可能涵蓋使用者填寫表單到送出。

但要注意單元測試並不會有外部依賴項,如:直接打 API 等待回傳值等,所以並不會因為回傳值而導致測試的結果產生變化。

在單元測試失敗時,因為是最小的測試單位,也很容易找出問題點,也因此單元測試相較於其他測試更好維護。

整合測試

整合測試通常用於測試幾個元件間的交互作用,及幾個元件協作後是否會有預期以外的失誤。

整合測試與單元測試的界定很模糊,不同的是整合測試會有外部環境依賴項,引用 WadeHuang 作者的 探討單元測試和整合測試的涵蓋範圍 文章內容如下:

測試案例成為整合測試的關鍵點是:測試案例是否包含與外部環境交互的邏輯,如時間、Session、Cookie、資料庫,硬體,網路等等不受程式控制的因素。

簡單來說,若測試案例無與外部環境交互的邏輯,則可以將測試案例視為單元測試

端對端測試(end-to-end)

端對端測試基本上是會花最多時間及成本的測試,而大部分的端對端測試是由人工去進行的。

將自己當成用戶,並由輸入網址開始,進行網站的一系列操作行為,確保網站的整體功能、流程皆能順利的運行,即為端對端測試。

總結

一開始在學習區別單元測試、整合測試時卡住蠻久的,後來通過作者 WadeHuang: 探討單元測試和整合測試的涵蓋範圍 及作者 Jack : Unit Test 實踐守則系列分享為我解答了疑惑,原來最主要判斷的依據就在於有沒有外部依賴項:如資料庫或第三方資源等,如果沒有的情況下,不論是測試一小段程式碼或一小段行為,都還涵蓋在單元測試的範圍內。


參考文章

https://ithelp.ithome.com.tw/articles/10229734
https://yu-jack.github.io/2020/09/14/unit-test-best-practice-part-1/
https://zh-hant.reactjs.org/docs/testing.html
https://www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/
https://blog.miniasp.com/post/2019/02/18/Unit-testing-Integration-testing-e2e-testing


上一篇
前言
下一篇
Jest 、 React Testing Library 差異
系列文
<< 測試魔法 >> 這能動嗎?不然就測測看好了!30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言